Subject: Questions Raised During AIW 6/28/94

From: "David D. Chen ((919)-254-6182 8-444)" <[email-masked]>
Date: Tue, 12 Jul 94 20:38:54 EDT

Ref:  Your note of Mon, 11 Jul 94 12:12:12 PDT (attached)

comments inserted.

Dave Chen
IBM Corp.

----------------------------- Note follows ------------------------------
>From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
>To: [email-masked]
>Subject: RE: Questions Raised During AIW 6/28/94
>Reply-To: [email-masked]
>Date: Mon, 11 Jul 94 12:12:12 PDT
>Message-Id: <[email-masked]>
>X-Mailer: SelectMAIL 1.0
>
>My comments are marked with AKB>
>
>Regards,
>
>Alan
>
>--- Begin (edited) Included Message ---
>
>
>Item 1: Should the MIB allow more than one DLSw entities?
>  I think the MIB should only allow one DLSw entity.  It simplifies
>  the MIB and satisfies most of implementations.  For those who
>  definitely have the need of running multiple DLSw entities in the
>  same box, I suggest that the technique of community name should be
>  used to distinguish them.  It seems to me that one of the key
>  reasons that running multiple DLSw's is separated one from the other.
>  It seems for the same reason, management of one should be separated
>  from the other.  Technique of community name can be used just for that.
>
>AKB> The MIB should only allow for one entity and I don't think there
>AKB> should be any text about community names as a technique (if vendors
>AKB> use that method, or any other, we should not specify the method
>AKB> as part of the standard).
>
Agree.  I just offer a solution (and sketch of a justification) for
those implmentations which run multiple DLSw entities.
>
>Item 2: Should the MIB allow transport connections other than TCP/IP?
>  yes, I would say.
>
>AKB> The MIB should use pointer to other MIB table entries to allow
>AKB> for other Transport, Network, or Data Link layers (as long as it
>AKB> can pass error free, sequenced frames, in theory SSP could be modified
>AKB> to run on top of it).  There may be some specifics for TCP that
>AKB> may prevent you from doing this however.
>
OK.  lets try our best.
>
>Item 4: Should the MIB be designed for configuring data link switches?
>  yes, I would say.  Of course, there are implementation specific
>  configuration stuff.  So, I would expect that enterprise specific
>  configuration objects to supplement for each individual implementation
>  needs.
>
>AKB> Watch out for number of MIB vars, usually configuration will
>AKB> require both Admin and Oper tables which increase the total number
>AKB> of objects.
>
OK.  Want to do configuration, or limited the number of MIB objects? :-)
What will be the limit of the number of MIB objects?  Can we worry about
it later, assuming all MIB objects are justified for its existence?

>Item 6: One set of Capabilities Exchange for all, or partner dependent,
>        ...
>  To simplify and meet most of implementation's need, I would say one
>  set for all (the whole box).  Enterprise specific MIB can be
>  developed for other needs.  (And partner's MIB should also be able to
>  tell what has been exchanged.)
>
>AKB> What do you mean by One set of Capabilities Exchange / partner
>AKB> dependent??  One set that everyone implements??  If that is so
>AKB> then you should at least try to attain it.
>
Originally it was thought that each DLSw maintains a set of CapEx
that will be sent to all its partners.  However, later, it was
mentioned that some implementations may allow user to specify one set
of CapEx info for each of its partners (or a group of partners).
The motion here is to limit one set (for a DLSw box) in std MIB.
Of course, enterprise specific MIB can be developed to meet those      .
needs.
>Other items (between 1-13):
>  These are all good objectives which we should try to accomplish.
>
>Dave Chen
>IBM Corp.
>
>--- End (edited) Included Message ---
>
>